The present invention relates to a method of organizing hierarchical data in a relational database. In particular, this invention relates to a method of organizing hierarchical data in a relational database that uses an outline numbering system like the conventional numbered outline commonly found in a book""s table of contents. The Outline Number is structured into digits separated by periods wherein the left most digit represents the highest-level parent, and each digit to the right represents progressively lower levels in the hierarchy.
The problem of choosing between a hierarchical database and a relational database comprises a fundamental problem in the art of database management and construction. In particular, many types of data conform to a hierarchical form or structure. For example, an employee organizational chart follows a hierarchical form. The company president sits at the top level of the hierarchy, and the next level would include the personnel that report to the president. This would continue on down until the chart placed each employee at the appropriate level in relation to each employee""s supervisor. Similar hierarchical structures apply to the structure of computer filesystems, wherein at the top of the hierarchy is a root directory with a number of subdirectories underneath and with directories under the each of the subdirectories, and so on. Another classic application of a hierarchical database is the bill-of-material (BOM) application. In this application a hierarchical, or tree, structure serves to represent all of the parts required to assemble an item. The item would consist of a number of subassemblies, and the subassemblies would in turn consist of subassemblies and so on. The hierarchy would consist of the item at the top and then a list of subassemblies all the way down to the lowest level part.
A hierarchical database works well to organize data where each data element in the database is placed in a strict hierarchical relationship to some other element. Hierarchical databases are designed to process and manipulate data in a manner that takes advantage of the hierarchical relationship between data elements. In this regard, hierarchical databases are conceptually easy to understand and organize, and changing the structure or arrangement of the elements comprises at least a conceptually straightforward task. Hierarchical databases, however, suffer from some major drawbacks. Foremost, is the fact that they lack the ability to easily manage any relationship between the elements of the database other than the hierarchical relationship. For example, an organizational chart captures only a very small portion of the relationships between the employees. The locations of the employees"" offices, special committee membership, and eligibility for benefits are examples of nonhierarchical relationships that would make a hierarchical database unsuitable for use. Accordingly, hierarchical databases do not work well to manage complex relationships between database elements.
As an alternative, relational database products exist that work well in managing complicated associations between information and data. For example, a document retrieval system could use a relational database to store information about related documents that would facilitate retrieval of documents that deal with similar subjects. The database could create a relationship between all documents that dealt with finance, or with legal matters, or with a specific person, or any other predefined relationship. Relational databases offer many benefits for software developers and database administrators, including a standard query language (SQL) and transaction processing suitable for mission-critical applications; however, relational databases do not easily adapt to storing hierarchical data. Accordingly, database managers and developers are often faced with selecting between a relational or hierarchical database, especially in consideration of the fact that many types of data require hierarchical and relational management.
The prior art describes several methods or devices to provide for cooperative development of hierarchical and relational data management. For example, U.S. Pat. No. 5,974,407 (Sacks) describes three categories of solutions to the problem: 1) the integration of separate hierarchical and relational databases along with the use of additional tools to support sharing between the two databases; 2) extending either the hierarchical or relational databases into the realm of the other database through the use of nonstandard Structured Query Language (SQL) programs; and 3) starting with one or the other database types and using native data structures to recreate the structure of the other type of database. However, prior art solutions involve increased complexity, extensive programming, and increased computational overhead.
More specific approaches to the problem using the first approach outlined above include various schemes to integrate hierarchical and relational databases. U.S. Pat. No. 5,724,577 (Exley et al.) describes a method of linking data stored in a hierarchical database with data stored in a relational database, which attempts to take advantage of arranging hierarchical data in an outline format. The method creates a table in a relational database that stores in a key field hierarchical outline heading numbers associated with particular data entries, thereby preserving the hierarchical information associated with each data element. Pointers are used to connect the data in the relational database with the data in the hierarchical database. Accordingly, the Exley et al. method requires the use of two databases. In addition, for reasons that will become apparent, by merely preserving the hierarchical information in a relational database the Exley et al. method does not create a relational database with any of the advantages of a hierarchical database. In other words, Exley et al. captures the hierarchical component of the data and stores it in a relational database, but does so in a manner that prevents efficient hierarchical processing of the data in the relational database.
U.S. Pat. No. 6,192,273 (Haegele) discloses a method that stores hierarchical data in a relational database table that includes a Caption Set Object Identifier (CSOID). The CSOID is a single number that stores all of the hierarchical information about a particular data entry. In the example offered in Haegele, the CSOID varies in length in multiples of three, wherein every set of three digits represents a particular level (or indent) in the hierarchy. Thus, the left most three digits would represent the position of a data item at the highest hierarchical level, and the right most three digits would represent the position of the data item at the lowest hierarchical level. While the method of Haegele represents an improvement on the method of Exley et al., in that it eliminates the need for multiple databases, it still suffers from the drawback that the arrangement of the hierarchical information does not allow for efficient hierarchical processing of the data in the relational database. The full extent of the deficiency of the Haegele data representation method will become apparent in reference to the present invention.
Accordingly, a need exists for an improved method of organizing hierarchical data stored in a relational database.
An object of the present invention comprises providing an improved method of organizing hierarchical data stored in a relational database.
These and other objects of the present invention will become apparent to those skilled in the art upon reference to the following specification, drawings, and claims.
The present invention intends to overcome the difficulties encountered heretofore. To that end, a relational database is provided with a plurality of data entries stored in the database. The data entries have a hierarchical relationship. The data entries are assigned an item identifier that uniquely identifies each of the data items. A multiple digit outline number is assigned to each of the data entries wherein the digits of the outline number correspond to the hierarchical levels of the data entries. A hierarchical level identifier is assigned to each of the data entries wherein the hierarchical level identifier represents the depth of the entry in the hierarchy and is equal to the number of non-zero digits in the outline number. An organizational table is created wherein the table includes a row for each of the data entries and the table includes multiple columns. The columns comprise a column for the item identifier, a plurality of outline number columns where each outline number column comprises one digit of the outline number such that each of the digits is stored in a separate column, and a hierarchical level column comprising the level identifier.